Patient care cards

ABSTRACT

Methods, computer systems, and computer readable media for a patient care card graphical user interface are provided. The patient care card graphical user interface comprises a requirements display area configured to display one or more clinical measures relating to a patient, and a visual indicator that changes depending on whether the at least one or more clinical measures has been met.

This application is related by subject matter to U.S. patent applicationSer. No. 12/982,137, filed Dec. 30, 2010 and entitled “Provider CareCards” and U.S. patent application Ser. No. 12/982,143, filed Dec. 30,2010 and entitled “Health Information Transformation System” each ofwhich is assigned or under obligation of assignment to the same entityas this application, and incorporated in this application by reference.

BACKGROUND

Traditionally, although a wealth of healthcare data exists with respectto a particular patient, the data is not in a form that easily utilizedby computer applications. As well, the healthcare data is oftendispersed throughout multiple sources, and it is difficult to assimilateand relate the same clinical concept from these multiple sources.Additionally, provider or patient graphical user interfaces that utilizethis healthcare data are not user-friendly or, in the case of providergraphical user interfaces, do not present the provider with acomprehensive view of a patient's state of health.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter. The present invention is defined by the claims.

Examples of the present invention are directed to methods, computersystems, and computer-readable media for use in transforming rawhealthcare data from disparate sources into relevant healthcare datathat may be utilized by a variety of healthcare applications. Thistransformation process occurs in a health information transformationsystem. As well, examples of the present invention are directed tographical user interfaces in the form of provider care cards and patientcare cards. Provider and patient care cards are built upon the relevantdata generated by the health information transformation system. Providercare cards are user-friendly, intuitive graphical user interfaces thatgive providers a variety of tools they can use to more effectively carefor their patients and improve the quality of healthcare they deliver.As well, patient care cards are also easy-to-use graphical userinterfaces that help patients to partner with their providers and assumea more active role in managing their health. The ability to transformraw healthcare data into relevant healthcare data, which then may beused, for example, to facilitate patient care through the use ofprovider and patient care cards, is an important advantage in thenever-ending quest to improve the quality of healthcare.

In one aspect of the invention, raw data is received from a plurality ofdata collectors, where the plurality of data collectors extract raw datafrom a plurality of raw data sources. In one aspect, the plurality ofdata collectors comprise electronic medical records crawlers, clinicaland administrative data collectors, claims data collectors, documentfeed collectors and medical device feed collectors. In turn, theplurality of raw data sources may comprise electronic medical records,images, claims, data from patients or providers, documents, and medicaldevices. The raw data is sorted into unstructured raw data, structureddata of non-standard nomenclature, and structured data of standardnomenclature. The sorted data is then transformed into relevant datathrough the use of natural language processing, nomenclature andontology mapping, and distributed adaptive knowledge processing. Therelevant data is loaded into a plurality of data repositories, andcomputer applications, including provider and patient care cards, areprovided access to the plurality of data repositories. The plurality ofdata repositories may comprise real time transaction processing datarepository, online analytical processing data repository, data mart datarepository, search index data repository, and custom data repository.

In another aspect of the invention, a graphical user interfacecomprising a provider care card is provided. In one aspect, the providercare card comprises a requirements display area configured to display atleast one or more clinical measures relating to at least one patient,and a measurements display area configured to display one or moremeasurements completed for one or more of the clinical measures. Inaddition, the invention comprises a first plurality of microdisplaysconfigured to display a visual indicator for each of the clinicalmeasures that has been met, and a second plurality of microdisplaysconfigured to display a visual indicator for each of the clinicalmeasures that has not been met. In another aspect, along with thefeatures outlined above, the provider care card also comprises the firstplurality of microdisplays and the second plurality of microdisplaysarranged over a time period ranging from at least an initial point ofprovider/patient contact to at least a current point of provider/patientcontact regardless of whether the clinical measure has been met or notmet. In yet another aspect, along with the features outlined above, thefirst plurality of microdisplays are shaded a first color to indicatethe clinical measure has been met, and the second plurality ofmicrodisplays are shaded a second color to indicate the clinical measurehas not been met.

In yet another aspect of the invention, a graphical user interfacecomprising a patient care card is provided. In one aspect, the patientcare card comprises a requirements display area configured to display atleast one or more clinical measures relating to a patient, and a visualindicator that changes depending on whether the clinical measure hasbeen met. In another aspect, the patient care card comprises arequirements display area configured to display at least one or moreclinical measures relating to a patient, and a measurements display areaconfigured to display one or more measurements completed for one or moreof the clinical measures relating to the patient. A trend display areais also provided that is configured to display at least one or moregraphical representations of the clinical measures relating to thepatient. As well, a visual indicator is provided that changes dependingon whether the one or more clinical measures has been met. In yetanother aspect of the invention, the patient care card comprises apatient input display area configured to receive inputs from thepatient, where the inputs correspond to at least one or more of theclinical measures relating to the patient. The patient input displayarea is in addition to the requirements display area, measurementsdisplay area, trend display area and visual indicator as outlined above.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are described in detail below with reference to the attacheddrawing figures, wherein:

FIG. 1 is a block diagram of an exemplary computing environment suitableto implement embodiments of the present invention;

FIG. 2 depicts an exemplary framework of a health informationtransformation system suitable to implement embodiments of the presentinvention;

FIG. 3 depicts a flow diagram of a method to transform healthinformation in accordance with an embodiment of the present invention;

FIGS. 4-6 depict exemplary graphical user interfaces of provider carecards in accordance with embodiments of the present invention; and

FIG. 7 depicts an exemplary graphical user interface of a patient carecard in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

The subject matter of the present invention is described withspecificity herein to meet statutory requirements. However, thedescription itself is not intended to limit the scope of this patent.Rather, the inventors have contemplated that the claimed subject mattermight also be embodied in other ways, to include different steps orcombinations of steps similar to the ones described in this document, inconjunction with other present or future technologies. Moreover,although the terms “step” and/or “block” might be used herein to connotedifferent elements of methods employed, the terms should not beinterpreted as implying any particular order among or between varioussteps herein disclosed unless and except when the order of individualsteps is explicitly stated.

Examples of the present invention are directed to methods, computersystems, and computer-readable media for use in transforming rawhealthcare data into relevant healthcare data that may be utilized by avariety of healthcare applications. The transformation process takesplace in a health information transformation system. As well, examplesof the present invention are directed to graphical user interfaces inthe form of provider care cards and patient care cards. Provider andpatient care cards are built upon the relevant data generated by thehealth information transformation system. Provider care cards areuser-friendly, intuitive graphical user interfaces that allow providersto more effectively care for their patients. As well, patient care cardsare also easy-to-use graphical user interfaces that help patients topartner with their providers and assume a more active role in managingtheir health. The ability to transform raw data into relevant healthcaredata, which then may be used, for example, to facilitate patient carethrough the use of provider and patient care cards, is an importantadvantage in the never-ending quest to improve the quality ofhealthcare.

In one aspect of the invention, raw data is received from a plurality ofdata collectors, where the plurality of data collectors extract raw datafrom a plurality of raw data sources. In one aspect, the plurality ofdata collectors comprise electronic medical records crawlers, clinicaland administrative data collectors, claims data collectors, documentfeed collectors and medical device feed collectors. In turn, theplurality of raw data sources may comprise electronic medical records,personal health records, images, documents, and medical devices. The rawdata is sorted into unstructured raw data, structured data ofnon-standard nomenclature, and structured data of standard nomenclature.The raw data is then transformed into relevant data through the use ofnatural language processing, nomenclature and ontology mapping, anddistributed adaptive knowledge processing. The relevant data is loadedinto a plurality of data repositories, and computer applications,including provider and patient care cards, are provided access to theplurality of data repositories. The plurality of data repositories maycomprise real time transaction processing data repository, onlineanalytical processing data repository, data mart data repository, searchindex data repository, and custom data repository.

In another aspect of the invention, a graphical user interfacecomprising a provider care card is provided. In one aspect, the providercare card comprises a requirements display area configured to display atleast one or more clinical measures relating to at least one patient,and a measurements display area configured to display one or moremeasurements completed for one or more of the clinical measures. Inaddition, the invention comprises a first plurality of microdisplaysconfigured to display a visual indicator for each of the clinicalmeasures that has been met, and a second plurality of microdisplaysconfigured to display a visual indicator for each of the clinicalmeasures that has not been met. In another aspect, along with thefeatures outlined above, the provider care card also comprises the firstplurality of microdisplays and the second plurality of microdisplaysarranged over a time period ranging from at least an initial point ofprovider/patient contact to at least a current point of provider/patientcontact regardless of whether the clinical measure has been met or notmet. In yet another aspect, along with the features outlined above, thefirst plurality of microdisplays are shaded a first color to indicatethe clinical measure has been met, and the second plurality ofmicrodisplays are shaded a second color to indicate the clinical measurehas not been met.

In yet another aspect of the invention, a graphical user interfacecomprising a patient care card is provided. In one aspect, the patientcare card comprises a requirements display area configured to display atleast one or more clinical measures relating to a patient, and a visualindicator that changes depending on whether the clinical measure hasbeen met. In another aspect, the patient care card comprises arequirements display area configured to display at least one or moreclinical measures relating to a patient, and a measurements display areaconfigured to display one or more measurements completed for one or moreof the clinical measures relating to the patient. A trend display areais also provided that is configured to display at least one or moregraphical representations of the clinical measures relating to thepatient. As well, a visual indicator is provided that changes dependingon whether the one or more clinical measures has been met. In yetanother aspect of the invention, the patient care card comprises apatient input display area configured to receive inputs from thepatient, where the inputs correspond to at least one or more of theclinical measures relating to the patient. The patient input displayarea is in addition to the requirements display area, measurementsdisplay area, trend display area and visual indicator as outlined above.

Having briefly described embodiments of the present invention, anexemplary operating environment suitable for use in implementingembodiments of the present invention is described below. FIG. 1 is anexemplary computing environment (e.g., medical-informationcomputing-system environment) with which embodiments of the presentinvention may be implemented. The computing environment is illustratedand designated generally as reference numeral 100. Computing environment100 is merely an example of one suitable computing environment and isnot intended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the computing environment100 be interpreted as having any dependency or requirement relating toany single component or combination of components illustrated therein.

The present invention might be operational with numerous other generalpurpose or special purpose computing system environments orconfigurations. Examples of well-known computing systems, environments,and/or configurations that might be suitable for use with the presentinvention include personal computers, server computers, hand-held orlaptop devices, multiprocessor systems, microprocessor-based systems,set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above-mentioned systems or devices, and thelike.

The present invention might be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Exemplary program modules comprise routines,programs, objects, components, and data structures that performparticular tasks or implement particular abstract data types. Thepresent invention might be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules might be located in association with localand/or remote computer storage media (e.g., memory storage devices).

With continued reference to FIG. 1, the computing environment 100comprises a general purpose computing device in the form of a controlserver 102. Exemplary components of the control server 102 comprise aprocessing unit, internal system memory, and a suitable system bus forcoupling various system components, including database cluster 104, withthe control server 102. The system bus might be any of several types ofbus structures, including a memory bus or memory controller, aperipheral bus, and a local bus, using any of a variety of busarchitectures. Exemplary architectures comprise Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronic Standards Association (VESA) local bus,and Peripheral Component Interconnect (PCI) bus, also known as Mezzaninebus.

The control server 102 typically includes therein, or has access to, avariety of computer-readable media, for instance, database cluster 104.Computer-readable media can be any available media that might beaccessed by control server 102, and includes volatile and nonvolatilemedia, as well as, removable and nonremovable media. Computer-readablemedia might include computer storage media. Computer storage mediaincludes volatile and nonvolatile media, as well as removable andnonremovable media implemented in any method or technology for storageof information, such as computer-readable instructions, data structures,program modules, or other data. In this regard, computer storage mediamight comprise RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVDs) or other optical diskstorage, magnetic cassettes, magnetic tape, magnetic disk storage, orother magnetic storage device, or any other medium which can be used tostore the desired information and which may be accessed by the controlserver 102. Combinations of any of the above also may be included withinthe scope of computer-readable media.

The computer storage media discussed above and illustrated in FIG. 1,including database cluster 104, provide storage of computer-readableinstructions, data structures, program modules, and other data for thecontrol server 102.

The control server 102 might operate in a computer network 106 usinglogical connections to one or more remote computers 108. Remotecomputers 108 might be located at a variety of locations in a medical orresearch environment, including clinical laboratories (e.g., moleculardiagnostic laboratories), hospitals and other inpatient settings,veterinary environments, ambulatory settings, medical billing andfinancial offices, hospital administration settings, home healthcareenvironments, and providers' offices. Providers may comprise a treatingphysician or physicians; specialists such as surgeons, radiologists,cardiologists, and oncologists; emergency medical technicians;physicians' assistants; nurse practitioners; nurses; nurses' aides;pharmacists; dieticians; microbiologists; laboratory experts; laboratorytechnologists; genetic counselors; researchers; veterinarians; students;and the like. The remote computers 108 might also be physically locatedin nontraditional medical care environments so that the entirehealthcare community might be capable of integration on the network. Theremote computers 108 might be personal computers, servers, routers,network PCs, peer devices, other common network nodes, or the like andmight comprise some or all of the elements described above in relationto the control server 102. The devices can be personal digitalassistants or other like devices.

Exemplary computer networks 106 comprise local area networks (LANs)and/or wide area networks (WANs). Such networking environments arecommonplace in offices, enterprise-wide computer networks, intranets,and the Internet. When utilized in a WAN networking environment, thecontrol server 102 might comprise a modem or other means forestablishing communications over the WAN, such as the Internet. In anetworked environment, program modules or portions thereof might bestored in association with the control server 102, the database cluster104, or any of the remote computers 108. For example, variousapplication programs may reside on the memory associated with any one ormore of the remote computers 108. It will be appreciated by those ofordinary skill in the art that the network connections shown areexemplary and other means of establishing a communications link betweenthe computers (e.g., control server 102 and remote computers 108) mightbe utilized.

In operation, an organization might enter commands and information intothe control server 102 or convey the commands and information to thecontrol server 102 via one or more of the remote computers 108 throughinput devices, such as a keyboard, a pointing device (commonly referredto as a mouse), a trackball, or a touch pad. Other input devicescomprise microphones, satellite dishes, scanners, or the like. Commandsand information might also be sent directly from a remote healthcaredevice to the control server 102. In addition to a monitor, the controlserver 102 and/or remote computers 108 might comprise other peripheraloutput devices, such as speakers and a printer.

Although many other internal components of the control server 102 andthe remote computers 108 are not shown, those of ordinary skill in theart will appreciate that such components and their interconnection arewell known. Accordingly, additional details concerning the internalconstruction of the control server 102 and the remote computers 108 arenot further disclosed herein.

Health Information Transformation System

Turning now to FIG. 2, an exemplary framework of a health informationtransformation system 200 is provided. It will be understood by those ofordinary skill in the art that the arrangement shown in FIG. 2 is merelyexemplary. While the health information transformation system isdepicted as a single unit, one skilled in the art will appreciate thatthe health information transformation system is scalable. For example,the health information transformation system may in actuality include aplurality of computing devices in communication with one another.Moreover, the single unit depictions are meant for clarity, not to limitthe scope of embodiments in any form.

A receiving component 206 is configured to receive raw data from aplurality of raw data collectors 204, where plurality of raw datacollectors 204 is configured to collect raw data from a plurality of rawdata sources 202. In one aspect of the invention, raw data sources 202may comprise electronic medical record sources, images, documents, andmedical devices. In turn, electronic medical record sources may compriseelectronic clinical documents such as images, clinical notes, summaries,reports, analyses, or other types of electronic medical documentationrelevant to a particular patient's condition and/or treatment.Electronic clinical documents contain various types of informationrelevant to the condition and/or treatment of a particular patient andcan include information relating to, for example, patient identificationinformation, images, physical examinations, vital signs, past medicalhistories, surgical histories, family histories, histories of presentillnesses, current and past medications, allergies, symptoms, pastorders, completed orders, pending orders, tasks, lab results, other testresults, patient encounters and/or visits, immunizations, physiciancomments, nurse comments, other caretaker comments, and a host of otherrelevant clinical information. Images may comprise radiographic images,graphs, pictures, photographs, tables, and the like. Likewise, documentsmay comprise physician notes, physician reports, letters, and such.Finally, medical devices may comprise holter monitors, event monitors,post-event recorders, pre-symptom memory loop recorders, autodetectrecorders, implantable loop recorders, glucose monitoring devices, vitalsigns monitors, and such. Raw data sources 202 may be disparate innature in that the raw data may be extracted from a variety of differentsources as outlined above, and/or from different healthcare facilitiesand different providers.

Continuing, plurality of raw data collectors 204 may comprise electronicmedical records crawlers, clinical and administrative data collectors,claims data collectors, document feed collectors, and medical devicefeed collectors. In one aspect of the invention, raw data collector 204collects Health Level Seven (HL7) or Continuity of Care Document (CCD)data. HL7 and CCD develop standards for the electronic exchange ofhealthcare information and is involved in the sharing of thisinformation. In another aspect of the invention, raw data collector 204collects Electronic Data Interchange (EDI) data. In one aspect, EDIinvolves the electronic exchange of standardized information pertainingto insurance claims. EDI data includes uniform data extracted fromclaims originating from different insurance companies. As well, raw datacollector 204 may obtain or collect raw data through e-mail, facsimile,retrieval from the document source, as well as from the medical devicesdiscussed above.

After the raw data is received by receiving component 206, it is sortedby a sorting component 208 into structured data of standard nomenclature210, structured data of non-standard nomenclature 212, and unstructuredraw data 214. Structured data of standard nomenclature 210 may comprisedata that is in a computer-useable format suitable for use by adistributed adaptive knowledge engine component 222. For example, datais structured if it is coded with the proper InternationalClassification of Diseases, 9^(th) Revision, Clinical Modification(ICD-9-CM) code. In turn, the data has standard nomenclature if it is ina computer-useable language such as Systemized Nomenclature of Medicine(SNOMED) or Logical Observation Identifiers Names and Codes (LOINC). Byway of illustrative example, and not by limitation, structured data ofstandard nomenclature 210 may comprise clinical and administrative datathat conforms to the standards set forth by HL7 or otherstandard-setting bodies, as well as insurance claims informationretrieved from EDI.

Continuing, structured data of non-standard nomenclature 212 maycomprise data that needs additional processing before it is suitable forprocessing by distributed adaptive knowledge engine component 222. Forexample, the data might have the proper ICD-9-CM code but not be in astandard nomenclature, such as, for example SNOMED or LOINC. Structureddata of non-standard nomenclature 212 may comprise patient informationobtained from an electronic medical records source. By way ofillustrative example, a piece of patient-specific raw data extractedfrom an electronic medical record source may be the term “pityriasis.”The term “pityriasis” has the proper ICD-9-CM code of, for example,696.3, but it is not in standard SNOMED nomenclature. The term“pityriasis” is given standard SNOMED nomenclature (i.e. 77252004). Nowthe term “pityriasis” can be processed by distributed adaptive knowledgeengine component 222. Additionally, unstructured raw data 214 maycomprise data obtained from a provider's typed reports, notes, documentsand letters. This data is not structured correctly and is not instandard nomenclature. Unstructured raw data 214 needs to be convertedfrom human speech or documentation to a computer-useable language.

A transforming component 216 transforms the sorted data into relevantdata through the use of a natural language processing component 218, anomenclature and ontology mapping component 220, and distributedadaptive knowledge engine component 222. In one embodiment, naturallanguage processing component 218 transforms unstructured raw data 214into structured data of non-standard nomenclature 212 or structured dataof standard nomenclature 210.

As mentioned above, unstructured raw data is converted from human speechor input into a computer-useable language using natural languageprocessing component 218. An exemplary natural language processingsystem may include Discern nCode™ by Cerner. By way of illustrativeexample, natural language processing component 218 scans a physician'sdictated note and identifies clinical concepts with codified meanings.For example, a physician's note pertains to a patient who has previouslybeen diagnosed with diabetes and is now suffering from diabeticretinopathy. Natural language processing component 218 identifies theclinical concept “diabetic” and the clinical concept “retinopathy.” Bothof these terms have an established codified (i.e. ICD-9-CM code)meaning. Next, natural language processing component 218 labels theidentified clinical concepts as positive, suspected, or negative basedon the analysis, understanding, and context of the text within the note.In this case, the clinical concepts “diabetic” and “retinopathy” wouldboth be labeled positive. Natural language processing component 218 thentranslates the clinical concept into a health concept. Using the examplegiven above, the clinical concept “diabetic” plus “retinopathy” istranslated into a health concept “diabetic retinopathy” by applying thecorrect ICD-9-CM codes and the standard SNOMED nomenclature. The healthconcept “diabetic retinopathy” is now considered structured data ofstandard nomenclature 212.

In another aspect, unstructured raw data 214 may be transformed intostructured data of non-standard nomenclature. As mentioned above, theunstructured data is transformed into structured data by codifying thedata. But the raw data may be given non-standard nomenclature, such as,for example Multum®, instead of standard nomenclature. The non-standardnomenclature may be used if the standard nomenclature is not complete,or does not have the level of detail required with respect to a specificpiece of raw data. As well, only non-standard nomenclatures that arealready mapped into the system will be utilized.

Nomenclature and ontology mapping component 220 is configured totransform structured data of non-standard nomenclature 212 intostructured data of standard nomenclature 210. By way of illustrativeexample, nomenclature and ontology mapping component 220 receivesstructured data of non-standard nomenclature 212 comprising a discretehealth concept such as “skin eruption” or “rash exanthem” and associatesthat discrete health concept with a broader health concept such as“eruption of skin.” In turn, the broader health concept, “eruption ofskin,” may be associated with a still broader health concept “rash,”where “rash” is structured data of standard nomenclature 210 suitablefor processing by distributed adaptive knowledge engine component 222.Still further, nomenclature and ontology mapping component 220 mayreceive structured data of non-standard nomenclature 212 in the form ofrelated discrete health concepts such as “skin eruption,” “comedone,”“weal,” and “pityriasis” and associate the related discrete healthconcepts with the broader health concept “eruption of skin.” In turn,based on existing relationships within nomenclature and ontology mappingcomponent 220, the broader health concept “eruption of skin” isassociated with the health concept “rash”, where “rash” is structureddata of standard nomenclature 210.

Distributed adaptive knowledge engine component 22 is configured totransform structured data of standard nomenclature 210 into relevantdata. In one aspect of the invention, distributed adaptive knowledgeengine component 222 may be an artificial intelligence (AI) engineconfigured to provide decision support concerning which structured dataof standard nomenclature 210 should be selected and sent on in the formof relevant data to a loading component 224 for eventual loading into aplurality of data repositories 226. In general terms, distributedadaptive knowledge engine component 222 utilizes multi-agents thatcollaborate with each other and interface with external systems,services and users and has the ability to monitor changes andincorporate past knowledge into decision making in order to generate andevaluate alternative plans or adapt plans to handle conflict resolutionand critical constraints. A multi-agent virtual operating systemprovides efficient means to build complex systems composed of autonomousagents with the ability to be reactive, persistent, autonomous,adaptable, mobile, goal-oriented, context aware, cooperative and able tocommunicate with other agents and non-agents. Intelligence is achievedwithin agents by way of support provided by a rich ontology within asemantic network. For example, a multi-level of collaborating agentsallows low level agents to transform data so that it can be passed on toanother agent, and to continue the data transformation until the datahas been completely transformed from bits of data which may sometimesrepresent incomplete, outdated, or uncertain data, to a form a usablecollection of data with rich meaning. In this example, when it becomesnecessary to attack complex problems the agent is permitted to constrainand narrow its focus at an individual level to support decomposition.Domain specific agents can be leveraged in some embodiments to use anontology to manage local domain specific resources.

Distributed adaptive knowledge engine component 222 handles processmanagement, scheduling, memory, resource management, Input/Output(“I/O”), security, planning, as well as other processes traditionallyhandled by operating systems, and in some embodiments includes memory,which may include short, intermediate, and/or long term memory, I/O,internal agent blackboard, context switching, kernel, swapper, deviceresource management, system services, pager, process managers, andlogging, auditing, and debugging processes. In some embodiments,distributed adaptive knowledge engine component 222 is a distributedvirtual operating system. Distributed adaptive knowledge enginecomponent 222 may also include a Symantec Engine, which provides theplatform for complex agents and primitive agents. On top of the agentslayers are applications, such as agent solver. Agent solvers may includea finite state machine instantiated and executed to determine apatient's conditions and recommended treatments. Other agent solvers mayinclude searching, including heuristic and traditional searching; list;constraint satisfaction; heuristic informed; hill climbing; decisiontree; simulated annealing; graph search; A* search; genetic algorithm;evolutionary algorithm; tabu search; logical inference; fuzzy logic;forward and backward chaining rules; multi-criteria decision making;procedural; inductive inference; pattern recognition; neural fuzzynetwork; speech recognition; natural language processing; decomposition;divide and conquer; goal tree and sub-goal tree; state machine; functiondecomposition; pattern decomposition; and other decision processingapplications.

As well, distributed adaptive knowledge engine component 222 may performsome interpretation on structured data of standard nomenclature 210,where the interpretation takes place outside the context of a specificpatient. By way of illustrative example, and not by limitation,distributed adaptive knowledge engine component 222 may identifystructured data of standard nomenclature 210 corresponding to acreatinine value of 2.0 milligrams per deciliter (creatinine is ameasure of kidney function), where normal levels of creatinine rangefrom 0.5 milligrams per deciliter to 1.2 milligrams per deciliter.Without looking at the creatinine value in the context of a specificpatient, distributed adaptive knowledge engine component 222 determinesthat the creatinine is elevated and, based on this determination,selects and transforms this piece of structured data of standardnomenclature 210 into relevant data.

Loading component 224 is configured to load the relevant data into aplurality of data repositories 226. In one aspect of the invention,plurality of data repositories 226 may be optimized for specific usecases. By way of illustrative example, at least one data repository ofplurality of data repositories 226 may be optimized to store relevantdata pertaining to Patient X or Provider Y. The relevant data wouldcomprise all of the relevant data specifically relating to Patient X orProvider Y. A data repository that is optimized for this kind of use issaid to be identified and may be suitable for providing in-depthinformation on Patient X or Provider Y. On the other hand, another datarepository of plurality of data repositories 226 may be optimized tostore a small subset of relevant data corresponding to a plurality ofdifferent patients or providers. A data repository optimized for thiskind of use is said to be de-identified and may be suitable, forexample, for providing a specific piece of health information on allpatients residing within a certain zip code area.

In another aspect of the invention, plurality of data repositories 226may comprise a master patient index, where a master patient indexreferences all patients known to an area, healthcare facility,organization, enterprise, and the like. In yet another aspect of theinvention, plurality of data repositories 226 may comprise at least oneof real-time transaction processing data repository, online analyticalprocessing data repository, search index data repository, data mart datarepository, and custom data repository. Real-time transaction processingdata repository stores relevant data used in real-time transactionprocessing. These transactions are processed as they occur and are notpart of a group of transactions. Further, online analytical processingdata repository stores relevant data that can be used to comparerelationships between different sets of data. Search index datarepository may be used to quickly and accurately locate relevantdocuments in response to a search query, while data mart data repositorystores relevant data used to create decision support. Finally, customdata repository may be customized according to the preferences of auser.

In one aspect of the invention, online analytical processing datarepository may be either identified or de-identified. As outlined above,online analytical processing data repository may be identified if itstores relevant data that relates to a specific patient or provider.Alternatively, online analytical processing data repository may bede-identified if it stores relevant data relating to a plurality ofpatients. In another aspect of system 200, data mart data repository mayalso be identified or de-identified. In one aspect, relevant data storedin an identified data mart data repository may be used to createdecision support for a patient as outlined further below.

An access component 228 is configured to provide access to plurality ofdata repositories 226. In one aspect of the invention, access component228 may provide access to healthcare applications and servicescomprising at least one of eVisit, care card, condition management,evaluation and management (E/M) coding, quality reporting, and searchapplications. Still further, in another aspect, access component 228 mayprovide a provider care card application and a patient care cardapplication access to data mart data repository. These two applicationsuse the relevant data stored in data mart data repository to creategraphical user interfaces in the form of provider care cards and patientcare cards. Provider care cards have a number of different capabilitiesthat assist providers in caring for their patients, while patient carecards are designed to help patients assume a more active role inmanaging their health.

As mentioned above, relevant data stored in data mart data repositorymay be used to create decision support for a patient. Theprovider/patient care card application, in one example, may utilize atypical rules engine to create decision support for the care cardapplication. The rules engine may determine actions or dispositions withrespect to a patient by applying a set of pre-defined rules to apre-determined number of conditions or treatments. In another aspect,the provider/patient care card application may utilize an artificialintelligence (AI) engine, such as, for example, distributed adaptiveknowledge engine component 222, that uses relevant data stored in anidentified data mart data repository to provide flexible, adaptive,decision support for a patient. For example, the AI engine in the carecard application may use the relevant data along with a set ofparameters that specify information about drugs, contra-indications,diagnoses, conditions, and the like to instantiate and apply a programto determine recommended treatments for a patient. This process takesplace in the context of a specific patient unlike both the rules enginementioned above. By way of illustrative example, and not by limitation,the AI engine in the care card application identifies relevant datastored in data mart data repository corresponding to a creatinine levelof 2.0 milligrams per deciliter for Patient X. A typical rules enginewould automatically generate an alert to a provider based on theelevated level. But distributed adaptive knowledge engine componentlooks at the creatinine level in the context of Patient X. Patient X,for example, has end-stage renal disease and will always have anelevated creatinine level. Distributed adaptive knowledge enginecomponent processes all of the relevant data relating to Patient X anddetermines that while the creatinine level is elevated in general, analert does not need to be provided because the creatinine level iswithin normal range for Patient X.

Turning now to FIG. 3, a flow diagram of a method 300 to transform rawhealthcare data into relevant healthcare data is provided. Theinformation outlined above with respect to FIG. 2 is also applicable tomethod 300. At step 302, raw data is received from a plurality of datacollectors, where the plurality of data collectors extract raw data froma plurality of data sources. At step 304 the raw data is sorted bymaking a determination as to whether the raw data is structured. If theraw data is structured, a determination is made at step 305 as towhether the structured data has standard nomenclature or non-standardnomenclature. If the raw data is structured and has standardnomenclature it is transformed at step 310 into relevant data throughdistributed adaptive knowledge processing. If it is determined at step305 that the raw data is structured but does not have standardnomenclature, it is transformed at step 308 into relevant data throughnomenclature and ontology mapping, and distributed adaptive knowledgeprocessing. Returning to step 304, if it is determined that the raw datais not structured data, the raw data is transformed into relevant dataat step 306 through natural language processing, nomenclature andontology mapping, and distributed adaptive knowledge processing. At step312, the relevant data is loaded into a plurality of data repositories,and at step 314 access to the plurality of data repositories isprovided.

Provider Care Cards

Turning now to FIG. 4, an exemplary graphical user interface (GUI) 400of a provider care card is shown. As mentioned above, provider carecards are built upon relevant healthcare data generated by the healthinformation transformation system. These easy-to-use, flexible, adaptivecare cards allow providers to more effectively care for their patientsby providing them with a comprehensive view of their patient's health.In one aspect of the invention, GUI 400 comprises a requirements displayarea 402 configured to display at least one or more clinical measures418 relating to at least one patient, and a measurements display area404 configured to display at least one or more measurements 420completed for one or more clinical measures 418 relating to at least onepatient. As well, GUI 400 comprises a first plurality of microdisplays406 configured to display a first visual indicator for each of theclinical measures that have been met, and a second plurality ofmicrodisplays 408 configured to display a second visual indicator foreach of the clinical measures that have not been met. For example,immunization 406 has been met and not smoking 418 has not been met.Clinical measures 418 may comprise any health-related concept that isused by a provider in the care of a patient. Examples includeprescriptions, lifestyle, diet, activity, diseases, conditions, mentalhealth, over-the-counter medications, homeopathic medications, herbalremedies, allergies, family support, age, and many more. Clinicalmeasure 418 is considered met if the patient or provider has acted withrespect to clinical measure 418. For example, a clinical measurerelating to a lipid panel would be met if the patient or provider drew asample of the patient's blood and obtained a lipid panel.

In one aspect of the invention, requirements display area 402 maycomprise at least an Order and Prescription area 412, a Lifestyle area414, and a Tests, Labs, and Exams area 416. Order and Prescription area412 may have an antibiotics area that contains information, for example,on which antibiotics a patient is taking, or which antibiotics a patientis allergic to, a prescription area containing information, for example,on which prescriptions the patient is currently taking, a medicationarea that documents all over-the-counter medications the patient istaking, and an immunization area that may contain information on thecurrent immunization status of the patient.

Lifestyle area 414 may comprise a goals area containing information onprovider goals for a patient. Provider goals may include general goals,specific goals, long-range goals, or short-range goals for patient care.By way of illustrative example, a provider may have a bed-ridden patientsuffering from obesity, high blood pressure, and pressure sores. Theprovider's goals for this patient may include general, long-range goalssuch as having the patient lose weight and begin walking within the nextthree months, and specific, short-term goals such as having a homehealth nurse visit the patient and provide wound care for the pressuresores within the next week. Lifestyle area 414 may also comprise a dietarea relating to dietary goals and restrictions for the patient, anactivity area containing information on, for example, current activityand desired activity, and a smoking area containing information aboutthe patient's tobacco history. Still further, Tests, Labs, and Examsarea 416 may comprise such information as a lipid panel, depressionassessment, blood pressure screening, eye exam, foot exam, pap smear,blood metabolic panel, thyroid panel, and the like.

In another aspect of the invention, requirements display area 402 may becustomized to at least one or more conditions of the patient. Acondition may be defined as the presence of illness, disease, or a statenot normally present in the patient such as pregnancy. By way ofillustrative example, and not by limitation, a patient suffering fromcancer may have a cancer area within the requirements display area 402.The cancer area may contain clinical measures 418 specific to thatcondition such as a clinical measure 418 on how much radiation thepatient has received in the course of her cancer treatment, or aclinical measure 418 concerning clinical studies in which the patient isenrolled.

As mentioned above, measurements display area 404 is configured todisplay one or more measurements 420 completed for one or more clinicalmeasures 418 relating to a patient. Measurements 420 may comprisepatient compliance, cost of care, patient satisfaction, patientlifestyle compliance, patient goal compliance, results of blood work orprocedures, blood pressure readings, potentially avoidable complications(PAC), and the like. PACs may be defined as non-typical servicesassociated with the care of a patient with a chronic condition. Forexample, diabetic patients typically have circulatory problems andneurological problems especially with respect to their feet. A typicalservice for a patient that is being followed for diabetes is a regularfoot exam. A PAC associated with diabetes would be wound care for adiabetic patient with a foot ulcer who was not receiving regular footexams.

In one aspect of the invention, measurement display area 404 may beconfigured to display measurements trends for at least one or more ofmeasurements 420. Measurement trends for measurements 420 may be shown,for example, by an arrow, graph, table, chart, and such. This is useful,for example, when a provider is following the blood glucose levels of adiabetic patient. As well, measurement display area 404 may beconfigured to receive at least one or more measurements 420 from thepatient. Measurements 420 may be electronically sent by the patient,received via a telephone call from the patient and inputted by theprovider or someone from her staff, and the like.

Measurement display area 404 may also be configured to displaycomparisons between at least one or more measurements 420 of the patientand measurements 420 of a comparison group. The comparison may be atleast one of condition-based, outcome-based, demographic-based,financial-based, geographic-based, and such. By way of illustrativeexample, a provider may be interested in comparing the cost of care forPatient X who has diabetes. The provider could access a condition-basedand financial-based comparison of patient X and a comparison group. Thecomparison group could comprise other diabetic patients seen by theprovider, diabetics within a certain zip code, diabetic patients fromthe population at large, and so on. The use of comparisons gives theprovider important feedback regarding the quality of care the provideris delivering to her patient.

Continuing on, measurement display area 404 may be configured to displaya third visual indicator 422 if measurement 420 is abnormal and a fourthvisual indicator 424 if measurement 420 is normal. For example, thirdvisual indicator 422 indicates that the patient has an abnormal LDL, andfourth visual indicator 424 indicates that the patient's systolic bloodpressure is normal. By way of illustrative example, and not bylimitation, third visual indicator 422 may be colored red to alert theprovider that measurement 420 is abnormal. Additionally, fourth visualindicator 424 may be colored green to alert the provider thatmeasurement 420 is within normal range. In one aspect of the invention,an alert, notification, or questionnaire may be automatically sent tothe patient if measurement 420 is abnormal as shown by third visualindicator 422. The alert, notification or questionnaire may be sent viaemail, text message, automated phone call, and such. By way ofillustrative example, and not by limitation, a diabetic patient may beresponsible for monitoring his blood glucose levels at home and sendingthem to the provider. If the blood glucose levels are outside the normalrange, a questionnaire may be automatically sent to the patient throughelectronic mail asking the patient what his symptoms are and requestingthat a repeat blood glucose level be drawn and the results sent to theprovider.

In one aspect of GUI 400, first plurality of microdisplays 406 areshaded a first color to indicate clinical measure 418 has been met, andsecond plurality of microdisplays 408 are shaded a second color toindicate clinical measure 418 has not been met. But it should beunderstood that any number of visual indicators may be used to indicatewhether the clinical measure has been met/not met including words,symbols, patterns, and the like.

Additionally, at least one of second plurality of microdisplays 408 maybe actionable meaning that a provider can click on the microdisplay 408and initiate at least one of an ordering conversation, a quality measureconversation, a data review conversation, a document conversation, ascheduling conversation, a billing conversation, or a communicationconversation. Upon clicking at least one of second plurality ofmicrodisplays 408, the provider may be taken to computer interface thatallows the provider, for example, to retrieve or view a documentassociated with the patient, order a test, procedure, or service for thepatient, schedule the patient for a visit with the provider, retrievequality measures, or initiate a communication with the patient throughthe use of, for example, electronic mail, text messaging, and the like.Using the example set out above concerning the patient suffering fromobesity, hypertension, and pressure sores, an order conversation maycomprise the provider ordering a home health nurse to visit the patientsince the patient is bed-ridden in his home, while a documentconversation may comprise the provider retrieving a consult letter froma bariatric physician who recently saw the patient. In addition, acommunication conversation may comprise the provider sending anelectronic message to the patient inquiring as to the status of thepatient's pressure sores.

In another aspect of the invention, first plurality of microdisplays 406may have mouse hover capabilities allowing the provider to hover over atleast one of first plurality of microdisplays 406 and view informationconcerning that microdisplay. Such information may comprise lab results,examination results, procedure results, evaluation reports, and thelike. Additionally, first plurality of microdisplays 406 and secondplurality of microdisplays 408 may be organized into patient responsibletasks and provider responsible tasks. By way of illustrative example,and not by limitation, a patient responsible task may be to monitorblood pressure readings at home. The patient would be responsible fortaking the blood pressure reading and communicating this reading to theprovider through electronic mail, text messaging, a telephone call, andthe like. Likewise, a provider responsible task in the above example,may comprise ordering a prescription for antihypertensive medication ifthe blood pressure readings are above a certain level. The providercould accomplish this task, for example, by initiating an orderingconversation through second plurality of microdisplays 408.

FIG. 5 represents another exemplary graphical user interface (GUI) 500of a provider care card in accordance with an aspect of the presentinvention. GUI 500 comprises a requirements display area 502 configuredto display at least one or more clinical measures 518 relating to atleast one patient. Requirements display area 502 corresponds, forexample, to requirements display area 402 of FIG. 4. As well, GUI 500comprises a measurements display area 504 configured to display one ormore measurements 520 completed for one or more clinical measures 518relating to at least one patient. Continuing, GUI 500 has a firstplurality of microdisplays 506 configured to display a first visualindicator for each of the clinical measures 518 that have been met.First plurality of microdisplays 506 correspond generally, for example,to first plurality of microdisplays 406 of FIG. 4. Finally, GUI 500comprises a second plurality of microdisplays 508 configured to displaya second visual indicator for each of the clinical measures 518 thathave not been met. Second plurality of microdisplays 508 corresponds,for example, to second plurality of microdisplays 408 of FIG. 4.

Turning now to FIG. 6, another exemplary graphical user interface 600 ofa physician care card in accordance with an aspect of the presentinvention is shown. In one aspect, GUI 600 is configured to display atleast one or more conditions 605 of the patient allowing a provider acomprehensive view of her patient's health. In yet another aspect of theinvention, GUI 600 may be configured to allow the provider to select oneor more condition-centric views for the patient. For example, a providermay have a patient with multiple conditions, but the provider wishes tofocus on the condition that is the reason for the patient's presentoffice visit to the provider. The provider may limit the display of GUI600 to the condition at issue.

In addition, GUI 600 is configured to display a first plurality ofmicrodisplays 606 and a second set of microdisplays 608 corresponding tofirst plurality of microdisplays 406 and second plurality ofmicrodisplays 408 of FIG. 4. First plurality of microdisplays 606 andsecond plurality of microdisplays 608 may be arranged over a time periodranging from at least an initial point of provider/patient contact 601to at least a current point of provider/patient contact 603 regardlessof whether a clinical measure has been met. This view allows theprovider to see how well he or she is doing in meeting clinical measuresrelating to the patient. For example, the provider would likely bedelivering quality healthcare if the majority of visual indicatorsindicate that clinical measures have been met for the patient.Alternatively, if the majority of visual indicators indicate that theclinical measures have not been met for the patient, the provider coulduse this information to improve her practice. In addition, if there arepatient responsible tasks, the provider would be able to see how wellthe patient is doing in taking responsibility for her own health care bychecking to see if the visual indicators associated with the patientresponsible tasks indicate that the clinical measures have been met.

Patient Care Cards

Turning now to FIG. 7, an exemplary graphical user interface (GUI) 700of a patient care card in accordance with an embodiment of the presentinvention is provided. As mentioned above, patient care cards are builtupon the relevant healthcare data that is generated through the healthinformation transformation system. The patient care card is auser-friendly GUI that helps patients assume a more active role inmanaging their health.

In one aspect, GUI 700 comprises a requirements display area 702 that isconfigured to display at least one or more clinical measures 718relating to a patient. Also, GUI 700 comprises a visual indicator 708that changes depending on whether the at least one or more clinicalmeasures 718 has been met or not met. Clinical measures 718 may compriseany healthcare-related concept that is used in patient care. Clinicalmeasure 718 is met if a patient has acted with respect to clinicalmeasure 718. For example, clinical measure 718 for a diabetic patientmay include blood glucose levels. Clinical measure 718 is met if thepatient takes a blood glucose reading and inputs it into GUI 700.Additionally, visual indicator 708 comprises any number of indicatorssuch as, for example, color-coding, symbols, words, shading, and such.In one aspect, visual indicator 708 may be shaded a first color toindicate clinical measure 718 has been met, or visual indicator 708 maybe shaded a second color to indicate that clinical measure 718 has notbeen met.

GUI 700 may be configured to display at least one or more conditions ofthe patient. And, further, the displayed clinical measures 718 may becustomized to the at least one or more conditions of the patient. Thus,for example, a patient care card for a patient suffering from depressionand diabetes may display clinical measures 718 related to both of theseconditions such as blood glucose levels, a depression symptom checklist,and an exercise log.

In another aspect, GUI 700 comprises a requirements display area 702configured to display at least one or more clinical measures 718relating to a patient, a measurements display area 704 configured todisplay one or more measurements 720 completed for one or more clinicalmeasures 718 relating to the patient, a visual indicator 708 thatchanges depending on whether the at least one or more clinical measures718 has been met, and a trend display area 710 configured to display atleast one or more graphical representations of clinical measures 718relating to the patient. Measurements 720 may comprise results of bloodwork or procedures, blood pressure readings, blood glucose levels,exercise logs, completed symptom checklists, weight readings, and thelike. In turn, graphical representations associated with trend displayarea 710 may include bar graphs, scatter plots, pie charts, pictographs,line graphs, histograms, and the like.

In one aspect, measurement display area 704 may be configured to displaya first indicator if measurement 720 is abnormal, and a second indicatorif measurement 720 is within normal limits. First and second indicatorsmay include visual indicators such as color, shading, and words, andauditory indicators such as alarms, chimes, rings, and such. Ifmeasurement 720 is abnormal, a health alert display area 714 may beconfigured to display a message. In one aspect, the message may be sentby the patient's provider in response to the receipt of abnormalmeasurement 720. In another aspect, the message may be automaticallygenerated upon detection of abnormal measurement 720.

In another aspect, measurements display area 704 may be configured todisplay comparisons between measurement 720 of the patient andmeasurement 720 of a comparison group. The comparison may be at leastone of condition-based, demographic-based, cost-based, orgeographic-based. The use of comparisons allows the patient, forexample, to determine if the care she is receiving from her provider isnot only cost-efficient, but also effective.

Continuing on, GUI 700 may be configured to be actionable. In oneaspect, the action comprises a communication conversation with aprovider, or a scheduling conversation with a provider. For example,Patient X may be concerned with measurement 720. Patient X is able toclick on measurement 720 to access a communication screen. Patient Xthen inputs his message, and the message is electronically sent to thepatient's provider. Or Patient X may wish to schedule an appointmentwith his provider; Patient X may access a scheduling screen and schedulethe appointment. As well, GUI 700 may be configured to have hovercapabilities allowing the patient to hover over one or more clinicalmeasures 718 or measurements 720 and view healthcare information relatedto the one or more clinical measures 718 or measurements 720. By way ofillustrative example, and not by limitation, Patient X would like tohave more information about clinical measure 718 relating to weight.Patient X could hover over clinical measure 718 dealing with weight andaccess informational material on weight.

In another aspect, GUI 700 is configured to receive documentation,scheduling information, messages, measurements, or orders relating to atleast one or more clinical measures 718 from at least one or moreproviders. Thus, if a patient recently had blood drawn at her provider'soffice, the provider could electronically send the results to thepatient obviating the need for a phone call. If the blood work isabnormal, a message may be sent along with the results and displayed inhealth alert display area 714. The message would alert the patient andrequest that she contact the provider. In one aspect, a provider maysend a post-treatment survey to the patient. The feedback provided bythe survey furthers the goal of improving the quality of healthcaredelivered by the provider.

In yet another aspect, GUI 700 comprises a requirements display area 702configured to display at least one or more clinical measures 718relating to a patient, and a measurements display area 704 configured todisplay one or more measurements 720 relating to the patient. As well,GUI 700 comprises a first visual indicator 708 that changes depending onwhether the at least one or more clinical measures 718 has been met, atrend display area 710 configured to display at least one or moregraphical representations of the clinical measures 718 relating to thepatient, and a patient input display area 712 configured to receiveinputs from the patient, where the inputs correspond to at least one ormore of clinical measures 718 relating to the patient. Patient inputdisplay area 712 may be configured to receive inputs from the patientregarding whether to save measurement 720, change a value associatedwith clinical measure 718 (such as setting a new weight goal), or deletemeasurement 720 or clinical measure 718.

GUI 700 may also be configured to display a control panel, where thecontrol panel comprises at least one of a to-do list, a settings panel,or a dashboard panel. The dashboard panel may be configured to allow thepatient access to a variety of suitable healthcare-related applications.

CONCLUSION

As can be seen, embodiments of the present invention provide systems,methods, and computer-readable media for, among other things,transforming raw healthcare data into relevant data through the use ofnatural language processing, nomenclature and ontology mapping, anddistributed adaptive knowledge processing. This relevant data, in turn,may be used to create decision support for use by, among other things,provider and patient care card applications. These care cards have anumber of different capabilities that allow providers to moreeffectively care for their patients, and allow patients to moreeffectively partner with their providers in managing their health.

While the invention is susceptible to various modifications andalternative constructions, certain illustrated embodiments thereof areshown in the drawings and have been described above in detail. It shouldbe understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

The present invention has been described in relation to particularembodiments, which are intended in all respects to be illustrativerather than restrictive. Alternative embodiments will become apparent tothose of ordinary skill in the art to which the present inventionpertains without departing from its scope.

The invention claimed is:
 1. One or more non-transitory computer storagemedia having computer-useable instructions embodied thereon that, whenexecuted by a mobile device associated with a patient, cause the mobiledevice to display a graphical user interface that enables the patient toactively manage the patient's health, the graphical user interfacecomprising: a requirements display area configured to display aplurality of representations of a plurality of clinical measuresrelating to the patient, each representation of the plurality ofrepresentations corresponding to a single clinical measure of theplurality of clinical measures, the each representation of the pluralityof representations displayed in a separate display box, the eachrepresentation of the plurality of representations configured to displaya visual indicator upon the patient inputting on the mobile device oneor more values related to the representation's corresponding clinicalmeasure, the visual indicator comprising a triangle, wherein the one ormore values inputted by the patient are displayed within the triangle,and wherein the triangle is displayed within the each representation'sdisplay box, wherein the shape and orientation of the triangle indicateswhether the clinical measure has been met or not met; a separatemeasurements display area displayed simultaneously with the requirementsdisplay area and in the same viewable area of the graphical userinterface as the requirements display area, the measurements displayarea configured to display one or more measurements completed for thepatient, each measurement of the one or more measurements displayed in aseparate display box; and a separate trend display area displayedsimultaneously with the measurements display area and the requirementsdisplay area and in the same viewable area of the graphical userinterface as the measurements display area and the requirements displayarea, the trend display area configured to display a trending graph ofat least one of the plurality of clinical measures relating to thepatient.
 2. The graphical user interface of claim 1, wherein theplurality of representations of the plurality of clinical measures arecustomized based on at least one or more conditions of the patient. 3.The graphical user interface of claim 1, wherein the measurementsdisplay area is configured to display a first indicator if themeasurement is abnormal, and further wherein the measurement displayarea is configured to display a second indicator if the measurement isnormal.
 4. The graphical user interface of claim 1, wherein at least onerepresentation of the plurality of representations is selectable.
 5. Thegraphical user interface of claim 4, wherein selection of the at leastone representation initiates a communication conversation with aprovider.
 6. The graphical user interface of claim 1, wherein at leastone representation of the plurality of representations is configured tohave hover capabilities.
 7. The graphical user interface of claim 6,wherein the hover over the at least one representation initiates thepresentation of healthcare information relating to the at least onerepresentation's corresponding clinical measure.
 8. The graphical userinterface of claim 1, wherein the graphical user interface is configuredto receive documentation, messages, measurements, or orders relating toat least one clinical measure of the plurality of clinical measures fromat least one or more providers.